home *** CD-ROM | disk | FTP | other *** search
- From: kanze@gabi.gabi-soft.fr (J. Kanze)
- Message-ID: <KANZE.96Feb9160930@gabi.gabi-soft.fr>
- X-Original-Date: 09 Feb 1996 15:09:30 GMT
- Path: in2.uu.net!bounce-back
- Date: 09 Feb 96 15:41:46 GMT
- Approved: fjh@cs.mu.oz.au
- Newsgroups: comp.std.c++
- Subject: Re: class.union questions
- Organization: GABI Software, Sarl.
- References: <v01530500ad38ee830c96@[194.163.74.11]>
- <KANZE.96Feb5132431@slsvewt.lts.sel.alcatel.de>
- <4f7l8h$t0e@mulga.cs.mu.OZ.AU>
- In-Reply-To: fjh@munta.cs.mu.OZ.AU's message of 06 Feb 1996 10:27:03 PST
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMRtrV+EDnX0m9pzZAQGlagF/aADjuW1sBao2z96gg67ENHp5Ko553eRV
- W59j4JjGGGlT8LtuMr3PuHMhySaRrb+v
- =YXRJ
-
- In article <4f7l8h$t0e@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus
- Henderson) writes:
-
- > kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
- >
- > >dirk@becker.adviser.com (Dirk Becker) writes:
- > >
- > >|> In Section 9.6.1 Unions [class.union] there is a large collection of
- > >|> restrictions on the union itself and on candidate member classes.
- > >|> I would like to ask for reasons of several of them:
- > >
- > >One of the principle goals was that a union be compatible with a C
- > >union, at least in use. One of the rules is that the addresses of all
- > >of the elements in the union compare equal to the address of the union
- > >itself, when cast to the appropriate type.
- > >
- > >|> a) "A union shall not have base classes. A union shall not be used as
- > >|> a base class."
- > >
- > >Without this rule, you either break the address rule, or you impose
- > >some special class layout on unions.
- >
- > Nevertheless, contrary to what you seem to be implying,
- > that rule is not necessary for C compatibility.
- >
- > C++ structs can be very different to C structs, but C compatibility
- > is preserved for a certain category of C++ structs, namely POD-structs.
- > In the case of unions, the same thing could have been done -
- > rule (a) could have been dropped, yet C compatibility could still
- > have been be supported for POD-unions.
-
- True. But there is one intuitive fact that remains true for all
- structs: different (data) members have distinct addresses, and in fact
- occupy non-overlapping memory. The same intuitive fact for unions is
- that all (non-static) data members have the same address. (IMHO, of
- course.)
-
- There is one restriction that does seem to me totally ungrounded: not
- being able to inherit from a union. I don't think that this feature
- would be enormously useful, but I cannot think of a good reason why it
- should be banned. One of the classic solutions for handling C/C++
- compatibility is to put all of the data in a PODS, and inherit from it,
- using the derived class in C++, but allowing a pointer to it to
- automatically become a pointer to the PODS when passed to a C function
- declared to take such an address. The same argument could certainly be
- used for inheriting from unions. If I look in /usr/include/sys, I find
- lots of unions which could be potentially used this way.
- --
- James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
- Conseils, itudes et rialisations en logiciel orienti objet --
- -- A la recherche d'une activiti dans une region francophone
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. Moderation policy:
- http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
-